home *** CD-ROM | disk | FTP | other *** search
/ Libris Britannia 4 / science library(b).zip / science library(b) / INFO / DEVDRIV.ZIP / DEVDRIV.TXT
Text File  |  1985-11-08  |  9KB  |  214 lines
  1. Character-Oriented Device Drivers
  2. Robert A. Gibson
  3. Raleigh Personal Computer Club
  4.  
  5. In the September issue of the Exchange from IBM, there were two
  6. articles concerning the ANSI.SYS character-oriented device driver
  7. which comes with versions 2.0 and 2.1 of DOS.  This article is a general
  8. discussion of device drivers, which uses ANSI.SYS as an example.
  9.  
  10. First, refer to Chapters 13 and 14 of the DOS 2.0 manual for more  detail
  11. about device drivers, particularly the sections "Using Extended Screen
  12. and Keyboard Control" and "Installable Device Drivers".
  13.  
  14. How does a device driver function? In order to understand let's first
  15. look at how one might be used.
  16.  
  17. Application Program Input/Output Request
  18. ----------------------------------------
  19. 1  PROGRAM test(Input,Output);
  20.  
  21. 3  VAR
  22. 4   outfile : Text;
  23.  
  24. 6  BEGIN
  25. 7   Assign(outfile,"CON:");
  26. 8   Rewrite(outfile);
  27. 9   Writeln(outfile,"Testing 1 2 3");
  28. 10 END.
  29. -------------------------------------
  30. Figure 1.  Sample Pascal Program
  31.  
  32. In this sample Pascal program, line 7 associates the program file "outfile"
  33. with an operating system device called "CON:" (i.e., the console).
  34. In DOS, as in most operating systems, the console represents the keyboard
  35. and the display.  When the program outputs to the console (see line 9),
  36. the character sequence is supposed to be displayed on the screen, one
  37. character at a time.  If we have a character device driver defined for
  38. the console, then it would receive the characters one at a time and, in
  39. turn, display them on the console.
  40.  
  41. What, then, is the purpose of the console device driver?  With the
  42. device driver present, the application program doesn't have to
  43. be aware of the specifics about the output device.  It could be something
  44. simple, as a typewriter, or something exotic, as a holographic image
  45. device.  As far as the program is concerned, all it has to do is
  46. request that DOS output characters. DOS, in turn, requests that the
  47. driver output the characters, one at a time.
  48.  
  49. In addition to this simple interfacing task (the driver acts as
  50. an interface between the physical device and the operating system), a
  51. device driver can act as intelligent device controller.  It does this by
  52. scanning outgoing characters for special control sequences.  The
  53. "special sequences" recognized by the standard DOS 2.0 console device
  54. driver (and which originated with the ANSI X3.64-1979 standards committee)
  55. are defined in chapter 13 of the DOS manual.
  56.  
  57.  
  58. Since the console device driver acts as both an input and output
  59. interface, there is a buffering of characters in each direction.  On
  60. input, if a user presses keys before input has been requested, some of the
  61. characters (around 15) are held in the input buffer until a program, or
  62. DOS, requests input.  On the output side, if a program is displaying
  63. information, the data could contain one of the special control sequences,
  64. and the driver has to hold the characters until it can decide
  65. whether the sequence is, or is not, a control sequence.  We can diagram
  66. this relationship as follows:
  67.  
  68. Physical
  69. Devices   Console Device Driver
  70.            |---------------|
  71. |--------| | |-----------| | |------|
  72.  Display  <-- Output Buff <--
  73. |--------|   |-----------|    Appli-
  74.                               cation
  75. |--------|   |-----------|    Program
  76.  Keyboard --> Input  Buff -->
  77. |--------| | |-----------| | |------|
  78.            |---------------|
  79.  
  80. Figure 2 Relationship between Console Device Driver and Physical Devices
  81.  
  82. Now that we know (conceptually) how a character device driver works, how do
  83. we design and implement one?  Very carefully!  How come?  Consider the
  84. fact that when we power on (or reboot) the PC, it loads the
  85. operating system.  This, in turn, must load and initialize all of the
  86. device drivers BEFORE it begins to look for the AUTOEXEC.BAT file.  This
  87. means that if we are rewriting the console device driver, it has to
  88. function well enough to perform the systems output to the screen and
  89. input from the keyboard before we can even interactively debug it. If it
  90. doesn't, we have to power off and reboot with a backup copy of the
  91. operating system that doesn't contain our changed console device driver.
  92.  
  93. In order to have a functioning device driver, we need to know the kinds of
  94. requests that are going to be made of the driver by the operating system.
  95. If we look in chapter 14 of the DOS 2.0 manual, we find that the list of
  96. possible commands to be performed are:
  97.  
  98. ------------------------------------
  99.  0 - Initialization
  100.  1 - Media Check
  101.  2 - Build BPB
  102.  3 - IOCTL Input
  103.  4 - Input
  104.  5 - Non-Destructive Input (no wait)
  105.  6 - Input Status
  106.  7 - Input Flush
  107.  8 - Output
  108.  9 - Output (with verify)
  109. 10 - Output Status
  110. 11 - Output Flush
  111. 12 - IOCTL Output
  112. ------------------------------------
  113.  
  114. Fig 3. Device Driver Command Requests
  115.  
  116.  
  117. I'm not going into a detailed study of each of the possible device
  118. commands.  What I will do is give you an idea about what goes on in a
  119. character device driver for the console.
  120.  
  121. If you were to think of the device driver as written in a high level
  122. language such as Pascal, then the main portion of the program could be
  123. thought of as something like the following CASE statement, where each
  124. command request is satisfied by a separate procedure.
  125.  
  126. ------------------------------------
  127.    CASE command OF
  128.       0 : Init;
  129.       1 : Media_Check;
  130.       2 : Build_BPB;
  131.       3 : IOCTL_Input;
  132.       4 : Input_Request;
  133.       5 : Non_Destructive_Input;
  134.       6 : Input_Status;
  135.       7 : Input_Flush;
  136.       8 : Output_Request;
  137.       9 : Output_with_verify;
  138.      10 : Output_Status;
  139.      11 : Output_Flush;
  140.      12 : IOCTL_Output;
  141.    END;
  142. ------------------------------------
  143.  
  144. Figure 4. Case Statement
  145.  
  146. At boot time, DOS is loaded and looks for a file named "CONFIG.SYS" on the
  147. default drive.  This file defines the configuration information to be used
  148. by the operating system. Specifically, there will be a
  149. reference for each of the device drivers to be loaded.  In our case,
  150. one of the records will look something like "DEVICE=ANSI.SYS".
  151. This entry tells DOS to look for a file named "ANSI.SYS" on the default
  152. drive and directory and to load it as a device driver.
  153.  
  154. After it is loaded, the driver is invoked with an initialization
  155. request (command 0).  The driver performs whatever initialization
  156. processing is required, and it returns to DOS with an indication of
  157. how much storage is required.  In the case of the console device driver,
  158. the operating system then invokes the driver whenever a keyboard input
  159. request or display output request is initiated.
  160.  
  161. In order to perform keyboard input, DOS invokes the console device driver
  162. to determine if the user has pressed a key.  To do this, DOS will use
  163. either the "Input" or "Non-destructive Input (no wait)"
  164. device command.  The driver will check the input buffer and return the
  165. appropriate information to DOS.
  166.  
  167. In order to display text on the console, DOS will use either the
  168. "Output" or "Output (with verify)" command.  As the characters are
  169. received by the driver, they are checked to see if they conform to any
  170. of the special control sequences.  If they do not, they are placed on the
  171.  
  172.  
  173.  
  174. display.  If case you haven't noticed, the console device driver
  175. that comes with DOS 2.0 takes sequences that it thinks may be
  176. special control sequences, but which it eventually decides that it doesn't
  177. recognize.
  178.  
  179. What are these "special control sequences"?  If you look in chapter
  180. 13 of the DOS 2.0 manual, you'll see what I mean.  Each of the special
  181. output sequences begins with an escape character (CHR(27)), therein
  182. referred to as ESC, followed immediately by an open left bracket
  183. (CHR(91)).  If you're curious about how this particular character
  184. combination was chosen, take a look at the ANSI X3.64-1979 standards
  185. document (which in turn references ANSI X3.4-1977, which defines the
  186. ASCII character set).
  187.  
  188. After the sequence header comes the parameter information, followed by
  189. the function designation character. For example, the character sequence
  190. ESC[2] represents a complete console device driver output command sequence
  191. requesting the driver to erase all of the screen and position the cursor at
  192. the home position.
  193.  
  194. To recognize this sequence, the driver scans all of the output
  195. requests until it receives an ESC character, which may indicate the
  196. beginning of a command sequence.  As long as the characters conform to the
  197. format associated with command sequences, the driver continues to
  198. buffer them (remember, characters are being received one at a time).  At
  199. the point where the function designation character is encountered,
  200. the appropriate function can be performed using the specified
  201. parameter value(s).
  202.  
  203. The only question is, what does the driver do with the sequence when it
  204. detects an invalid control sequence (e.g., an invalid function letter)?
  205. The driver that comes with DOS 2.0 throws the sequence away.  I've
  206. written a driver with an option that allows the user to specify that
  207. invalid sequences should be displayed on the console.  This is only one of
  208. the many changes that I have completed in my rewrite of the
  209. console device driver.
  210.  
  211. If you are interested in reading an interesting article on the origin of
  212. the escape sequences used by ANSI.SYS, see page 365 of the April
  213. 1984 issue of Byte magazine.
  214.